Communication networks are ubiquitous in our connected world. Many larger communication networks comprise a plurality of interconnected network domains. In an exemplary mobile communication scenario, such network domains can be represented by a home network of a roaming user terminal on the one hand and a network visited by the roaming user terminal on the other.
Message exchanges between different network domains are often based on a session concept. There exist various messaging protocols suitable for the exchange of session-based messages between network elements located in different network domains. In the above example of message exchanges between network elements of a visited network and a home network, the Diameter protocol is often used. The Diameter protocol is an application layer protocol that provides an Authentication, Authorization and Accounting (AAA) framework for network operators.
A Diameter message contains in clear text the identity of the network element originating the message within a first network domain (e.g., a server in a visited network). Specifically, a Fully Qualified Domain Name (FQDN) identifies the originator of the message. Within the first network domain, originator identities in Diameter messages are processed for purposes such as message routing, message validation and loop prevention. When the Diameter messages leave the first network domain towards a second network domain, a potentially un-trusted operator of the second network domain, or any interceptor at the border of the two network domains, can easily derive the topology of the first network domain from the originator identities (and from other clear text information in the messages, such as optional message path information recorded by the messages while being routed in the first network domain).
For security and secrecy reasons, an operator of the first network domain is strongly interested in hiding the topological information derivable from any Diameter messages leaving the first network domain. The corresponding message processing operations could generally take place in a so-called Diameter Edge Agent (DEA). The DEA is a network element within the first network domain and interfaces the second network domain. In many implementations, the DEA can be considered as the only point of contact into and out of a particular network domain at the Diameter application level. Conventionally, the DEA is configured to primarily support scalability, resilience and maintainability from the perspective of the first network domain.
For the purpose of hiding the originator identity, also called internal host name hereinafter, the DEA could be configured to replace it in every Diameter message leaving the first network domain with an arbitrary (“dummy”) host name, also called external host name hereinafter. For a proper addressing of an incoming message that is received in response to an outgoing message in which the originator identity has been hidden, the internal host name has to be restored again in the incoming message. To this end, the DEA may maintain a mapping table that defines associations between pairs of internal and external host names.
It has, however been found that maintaining a mapping table at the DEA is disadvantageous from various perspectives. First, the DEA has to perform a dedicated look-up operation in the mapping table for each messaging step within a subscriber session that crosses the network domain boarder. Such look-up operations increase the overall system load. Further, memory resources that are consumed by the mapping table increase linearly with the number of active sessions, which limits the number of sessions that can be handled by one DEA. This disadvantage is aggravated by the fact that the mapping table is often replicated for security reasons in non-volatile memory. Still further, entries in the mapping table for sessions that have been silently terminated must be regularly cleaned up, which becomes an increasingly tedious task as the number of table entries rises. Also synchronization of DEAs that operate in a redundant manner becomes more complex because the mapping table has to be synchronized also.
It will be evident that the above drawbacks are not specific to the Diameter protocol or the roaming scenario exemplarily described above. Similar problems also occur in other messaging scenarios across domain borders when the messages potentially expose topological or other information.